Account management involves all of the tasks related to creating, mapping, changing, and organizing user and group information. After the user accounts and groups have been created, you can add objects and specify rights to them. When the users log on, they can view the objects using the BI launch pad or their custom web application. User management
In the Users and Groups management area, you can specify everything required for a user to access the SAP BusinessObjects Business Intelligence platform. You can also view the two default user accounts summarized by the following table.
Under the user-role-based licensing scheme, there are two roles that can be assignedto SAP BusinessObjects Business Intelligence platform users: BI Analyst BI Viewer
Each role is bundled with specific access levels to SAP BusinessObjects Business Intelligence platform applications. You cannot modify or override the access level to either user role. User roles apply to new user accounts created in the SAP BusinessObjects Business Intelligence platform or
existing users imported from third-party directory services such as Windows AD or LDAP.
Note: Click the License Key in the CMC for more information on your licensing scheme.
The BI Analyst role is designed for users who create content in the SAP BusinessObjectsBusiness Intelligence platform.
Users who edit or create reports, design and manage universes, or perform anyadministrative tasks in the CMC should be assigned the BI Analyst role.
| Inclined to build a profession as SAP MM Developer? Then here is the blog post on, explore SAP MM Training |
The BI Viewer role is designed primarily for content consumers. These users only view reports but do not modify content.
Users assigned to the BI Viewer role will be prevented by the system from creating content, modifying reports, and performing general administrative tasks in the system.
The BI Viewer role should not be assigned to users who need to:
Create reports
Update or modify reports
Perform administrative tasks using the CMC
Group management
Groups are collections of users who share the same account privileges; therefore, you may create groups that are based on department, role, or location. Groups enable you to change the rights for users in one place (a group) instead of modifying the rights for each user account individually. Also, you can assign object rights to a group or groups.
In the Users and Groups area, you can create groups that give a number of people access to the report or folder. This enables you to make changes in one place instead of modifying each user account individually. You can also view the several default group accounts summarized in the following table.
Note: To view available groups in the CMC, click Group List in the Tree panel. Alternatively, you can click Group Hierarchy to display a hierarchal list of all available groups.
| Account name | Description |
| Report Conversion Tool | Members of this group have access to the Report Conversion Tool application. |
| Translators | Members of this group have access to the translation |
| Universe Designer Users | Users who belong to this group are granted access to the Universe Designer folder and the Connections folder. They can control who has access rights to the Designer application. You must add users to this group as needed By default no user |
Enable the Guest account
Use: The Guest account is disabled by default to ensure that no one can log on to the SAP BusinessObjects Business Intelligence platform with this account. This default setting also disables the anonymous single sign-on functionality of the SAP BusinessObjects Business Intelligence platform, so users will be unable to access the BI launch pad without providing a valid username and password.
Procedure
New users and groups are created in the CMC. When you create a new user account in the CMC, you first must specify the user’s properties, before you configure group memberships for the user.
Groups are collections of users who share the same account privileges. For instance, you may create groups that are based on department, role, or location. Groups enable you to change the rights for users in one place (a group) instead of modifying the rights for each user account individually.
Also, you can assign object rights to a group or groups. Creating and modifying a user account
After a user account has been created, you can modify the account properties. The properties that can be modified include:
Account Name
The account name is the unique identifier for a user account and is the user name entered when logging into the SAP BusinessObjects Business Intelligence platform.
Full Name
This optional field is used to capture the user’s full name. It is recommended that you use this field, particularly when managing many users.
This optional field is used to add the user’s email address. This is for reference only. For example, if the user forgets their password sometime in the future, you can get their email address from this field to send them their password.
Description
This optional field is used to add information about the user, such as their position, department, or geographic location.
Enterprise Password Settings
User password settings allow you to change the password and password settings for the user. Global password settings can be configured in the Authentication area of the Central Management Console.
Connection Type This option specifies how the user connects to the SAP BusinessObjects Business Intelligence platform based on the license agreement.
Account is disabled
This checkbox allows the Administrator to deactivate the user account, instead of permanently deleting the account. This is useful when administering users who will be temporarily denied system access, such as employees taking parental leave Select the Account is a disabled checkbox to disable the Guest account. This makes it unavailable for use.
Assign Alias.
If a user has multiple accounts within the SAP BusinessObjects Business Intelligence platform, use this feature to link the accounts. This results in the user having multiple SAP BusinessObjects Business Intelligence platform login credentials that map to one SAP BusinessObjects Business Intelligence platform account.
You can also use the New Alias. button to create a new alias.
Create users
On the CMC home page, click Users and Groups.
Click Manage → New → New User. The New User dialog box appears. Select the Authentication Type.
To create an Enterprise user,
Select Enterprise from the Authentication Type list. Type the account name, full name, email, and description information. Use the description area to include extra information about the user or account. Specify the password information and settings.
To create a user that will log on using a different authentication type, select the appropriate option from the Authentication Type list, and type the account name. Specify how to designate the user account according to the options stipulated by your SAP BusinessObjects Business Intelligence platform license agreement.
If your license agreement is based on user roles, select one of the following options:
BI Viewer: access to SAP BusinessObjects Business Intelligence platform applications for all accounts under the BI Viewer role is defined in the license agreement. Users are restricted to access application workflows that are defined for the BI Viewer role. Access rights are generally limited to viewing business intelligence documents. This role is typically suitable for users who consume content through SAP BusinessObjects Business Intelligence platform applications.
BI Analyst: access to SAP BusinessObjects Business Intelligence platform applications for all accounts under the BI Analyst role is defined in the license agreement. Users can access all application workflows that are defined for the BI Analyst role. Access rights include viewing and modifying business intelligence documents. This role is typically suitable for users who create and modify content for SAP BusinessObjects Business Intelligence platform applications
If your license agreement is not based on user roles, specify a connection type for the user account. Choose Concurrent User if this user belongs to a license agreement that states the number of users allowed to be connected at one time. Choose Named User if this user belongs to a license agreement that associates a specific user with a license. Named user licenses are useful for people who require access to the BusinessObjects Business Intelligence platform regardless of the number of other people who are currently connected. that are defined for the
BI Analyst role. Access rights include viewing and modifying business intelligence documents. This role is typically suitable for users who create and modify content for SAP BusinessObjects Business Intelligence platform applications Click Create & Close.
Modify a user account
Use: Use this procedure to modify a user's properties or group membership.
The user will be affected if they are logged on when you are making the change.
Prerequisites: The user account must already exist before it can be modified.
Procedure: On the CMC home page, click Users and Groups.
Select the user whose properties you want to change.
Click Manage → Properties.
The Properties dialog box for the user appears.
Modify the properties for the user.
In addition to all of the options that were available when you initially created the account, you now can disable the account by selecting the Account is a disabled check box.
Any changes you make to the user account do not appear until the next time the user logs on.
Click Save & Close. Creating and modifying a group account
Once a group is created, you can modify its membership to include other groups. Groups can include other groups as subgroups.
Group names must be unique.
After a group is created, you can modify the properties. Properties can include:
Group Name Description Users Subgroups Member of Profiles Rights
Delete a user or group Use
You can delete a user or group when that user or group is no longer required.
Note: You cannot delete the default group Administrator and Everyone.
The users who belong to a deleted group will be affected by the change the next time they log on. The users who belong to the deleted group will lose any rights they inherited from the group.
Procedure
Adding users to groups
Once you have created a group structure, you will need to add users to the groups. You can add users to groups in the following ways:
Select the group, and then click Actions → Add Members to Group.
Select the user, and then click Actions → Member Of.
Select the user, and then click Actions → Join Group.
Add a user to one or more groups
In the Users and Groups management area of the CMC.
Select the user that you wish to add to a group. Click Actions→Join Group.
Note: All SAP BusinessObjects Business Intelligence platform users of the system are part of the Everyone group.
The Join Group dialog box appears. Select the group that you want to add the user to from the Available Groups list, and click > to move it to the Destination Group(s) list. Use SHIFT + click or CTRL + click to select multiple groups.
Click OK.
Add one or more users to a group
In the Users and Groups management area of the CMC, select the group.
Click Actions → Add Members to Group.
The Add dialog box appears.
Click the User list.
The Available users/groups list refreshes and display all user accounts in the system.
Select the user that you want to add to the group from the Available Users/groups list, and click >to move it to the Selected Users/groups list.
Note: To select multiple users, use the SHIFT + click or CTRL +click combination.
To search for a specific user, use the search field.
If there are many users on your system, click the Previous and
Next buttons to navigate through the list of users.
Click OK.
Result: The user(s) is added to the group.
Creating folders: To create a logical structure in which to store an organization's content you must create folders. Folders store objects and are used to organize documents.
You can use folders to separate content into logical areas. Every report or document must reside in a folder. Because you can set security at the folder level, you can use folders as a tool for controlling access to information. Object-level rights are either set explicitly for the object or inherited from the folder in which the object resides. Creating and managing folders is typically the responsibility of the SAP BusinessObjects BI platform administrator, but end users can be given the option to create their own folders and control the objects within their folders in the BI launchpad.
Managing folders in the SAP BusinessObjects BI platform is done in the folder management area of the Central Management Console.
Create a folder
Creating Categories
Categories provide an alternative way of organizing objects, and therefore an alternative way for users to navigate to them. For example, you could organize your content into departmental folders, and then use categories to create an alternate filing system that divides content according to different roles in your organization, such as managers or VPS.
This organizational model allows you to set security on groups of documents based on department or job role. There are two types of categories: corporate and personal. Corporate categories are created and administrated by administrators with the appropriate rights, and are only visible to groups and users who have the rights to view them; personal categories are created by individual users and are only visible to themselves.
There are two types of categories:
Corporate categories are created and administrated by administrators with the appropriate rights and are only visible to groups and users who have the right to view them.
Personal categories are created by individual users and are only visible to themselves.
Note: While all objects must reside in folders, category assignment is optional; therefore, it is important to note that:
While you can assign rights to a category as an object (that is, grant groups and users rights to it), the objects within the category cannot inherit rights set on the category itself.
An object in a category retains its affiliation with the folder it resides in.
An object can reside in multiple categories.
Create a category
The new category is added to the system. You can now click Manage → Properties to change settings for this category.
Assign an object to a category
Delete categories
Use: You can either remove or delete objects from a category. When you remove an object, you remove it from the category only. When you delete an object, you remove it from the category and also delete it from the system.
Procedure: Go to the Categories management area of the CMC.
Double-click the category from which you want to remove or delete an object.
If the category you want to delete is not at the top level, locate its parent category. Then make your selection.
To select multiple categories, hold down the CTRL or Option key and click each category so that you can delete several categories simultaneously.
Select the object or objects you want to remove or delete. Remove the object from the category or delete the object.
Click Actions → Remove From Category to remove the object from the category only. In this case, the object continues to exist in the system. Click Manage → Delete to remove the object from the category and at the same time delete it from the system.
Move a category
Use: When you move a category, any object assigned to the category maintains its association with it. All of the categories ' object rights are retained. For example, you may have a South American Sales category that is accessible only by salespeople in that region. You also have a World Sales category that contains worldwide sales reports needed by all salespeople. For a more intuitive organization, you want to move the region categories into the World Sales category. When you move the South American Sales category into the World Sales category, it retains its rights settings and associated objects, even though it has become a subcategory of the World Sales category.
Procedure: Go to the Categories management area of the CMC.
Select the category that you won't move.
If the category you want to move is not at the top level, locate its parent category. Then make your selection.
Click Organize → Move To.
Select the Destination category and add it to the Destination list.
If there are many categories on your system, use the Search title field to search, or click Previous, Next, and + to browse the category hierarchy.
Click Move.
The category you selected is moved to the new destination.
Rights play an important role in the SAP BusinessObjects Business Intelligence platform because they allow you to control access to your SAP BusinessObjects Business Intelligence platform content, rights enable you to delegate user and group management to different departments, and to provide your IT people with administrative access to servers and server groups.
Access levels
Access levels are groups of rights that users frequently need. They allow administrators to set common security levels quickly and uniformly rather than requiring that individual rights be set one by one. SAP BusinessObjects Business Intelligence platform comes with several predefined access levels. These predefined access levels are based on a model of increasing rights: Beginning with View and ending with Full Control, each access level builds upon the rights granted by the previous level.
Inheritance
Top-level folder security
Top-level folder security is the default security settings for each specific object type (for example Universes, Web Intelligence Application, Groups and Folders). Each object type has its own top-level folder (root folder) that all the objects below inherit rights from.
If there are any access levels common to certain object types that apply throughout the whole system, set them at the top-level folder specific to each object type. For example, if the Sales group requires the View access level to all folders, you can set this at the root level for Folders.
Folder-level security
Folder-level security enables you to set access-level rights for a folder and the objects contained within that folder. While folders inherit security from the top-level folder (root folder), subfolders inherit the security of their parent folder. Rights set explicitly at the folder level override inherited rights.
Object-level security
Objects in SAP BusinessObjects Business Intelligence platform inherit security from their parent folder. Rights set explicitly at the object level override inherited rights.
Setting Rights
How rights work in SAP Business Objects Business Intelligence platform
Rights are the base units for controlling user access to the objects, users, applications, servers, and other features in the SAP BusinessObjects Business Intelligence platform.
They play an important role in securing the system by specifying the individual actions that users can perform on objects.
Besides allowing you to control access to your SAP BusinessObjects Business Intelligence platform content, rights enable you to delegate user and group management to different departments and to provide your IT people with administrative access to servers and server groups.
It is important to recognize the difference between rights set on objects or folders, and rights set on principals (the users and groups) who access them.
For example, to give manager access to a particular folder, in the Folders area, you add the manager to the access control list (the list of principals who have access to an object) for the folder.
You cannot give the manager access by configuring the manager's rights settings in the "Users and Groups" area.
The rights settings for the manager in the Users and Group area are used to grant other principals (such as delegated administrators) access to the manager as an object in the system. In this way, principals are themselves like objects for others with greater rights to manage.
Each right on an object can be granted, denied, or unspecified. The SAP BusinessObjects Business Intelligence platform security model is designed such that, if a right is left unspecified, the right is denied. Additionally, if settings result in a right being both granted and denied to a user or group, the right is denied.
There is an important exception to this rule. If a right is explicitly set on a child object that contradicts the rights inherited from the parent object, the right set on the child object overrides the inherited rights. This exception applies to users who are members of groups as well. If a user is explicitly granted a right that the user's group is denied, the right set on the user overrides the inherited right.
Advanced rights settings
To provide you with full control over object security, the CMC allows you to set advanced rights. These advanced rights provide increased flexibility as you define security levels for objects at a granular level. Use advanced rights settings, for instance, if you need to customize a principal's rights to a particular object or set of objects.
Most importantly, use advanced rights to explicitly deny a user or group any right that should not be permitted to change when, in the future, you make changes to group memberships or folder security levels. The following table summarizes the options that you have when you set advanced rights.
Advanced rights
| Rights option | Description |
| Granted | The right is granted to a principal. |
| Not Specified | The right is unspecified for a principal. By default, rights set to Not Specified are denied. |
| Denied | The right is denied to a principal. |
| Apply to Object | The right applies to the object. This option becomes available when you click Granted or Denied. |
| Apply to Sub Objects | The right applies to sub-objects. This option becomes available when you click Granted or Denied. |
Type-specific rights
Type-specific rights are rights that affect specific object types only, such as Crystal reports, folders, or access levels. Type-specific rights consist of the following:
• General rights for the object type
These rights are identical to general global rights (for example, the right to add, delete, oredit an object), but you set them on specific object types to override the general global rights settings.
• Specific rights for the object type
These rights are available for specific object types only. For example, the right to export a report's data appears for Crystal reports but not for Word documents.
The diagram Type-specific rights example illustrates how type-specific rights work. Here right 3 represents the right to edit an object. Blue Group is denied Edit rights on the top-level folder and granted Edit rights for Crystal reports in the folder and subfolder.
These Edit rights are specific to Crystal reports and override the rights settings on a general global level. As a result, members of Blue Group have Edit rights for Crystal reports but not the XLF file in the subfolder. Type-specific rights are useful because they let you limit the rights of principals based on the object type.
Consider a situation in which an administrator wants employees to be able to add objects to a folder but not create subfolders. The administrator grants Add rights at the general global level for the folder and then denies Add rights for the folder object type. Rights are divided into the following collections based on the object types they apply to:
General
These rights affect all objects
Content
These rights are divided according to particular content object types. Examples of content object types include Crystal reports and Adobe Acrobat PDFs.
Application
These rights are divided according to which SAP BusinessObjects Business Intelligence platform application they affect. Examples of applications include the CMC and BI launch pad.
System
These rights are divided according to which core system component they affect. Examples of core system components include Calendars, Events, and Users and Groups.
Type-specific rights are in the Content, Application, and System collections. In each collection, they are further divided into categories based on the object type.
Troubleshooting user rights
Troubleshooting user rights can be a laborious undertaking for a systems administrator. The SAP BusinessObjects Business Intelligence platform contains two tools that are aimed at negating this challenge.
Permissions Explorer
The Permissions Explorer is aimed at making it easier to pinpoint the source of inherited user rights.
Security Query
The Security Query tool enables an administrator to list which objects a user can access and why. It also enables the administrator to interactively make changes to the security settings from the query result.
You can manage security settings for most objects in the CMC with the security options on the Manage menu. These options let you assign principals to the access control list for an object, view the rights that a principal has, and modify the rights that the principal has to an object.
Viewing rights for a principal on an object
Use: You can view the rights for a principal on an object using the Permissions Explorer tool. The Permissions Explorer saves time when trying to determine where inherited rights originate from in SAP BusinessObjects BI platform.
Procedure:
The Permissions Explorer dialog launches and displays a list of effective rights for the principal on the object. In addition, the Permissions Explorer lets you do the following:
Browse for another principal whose rights you want to view.
Filter the rights displayed according to these criteria:
Sort the list of rights displayed in ascending or descending order according to these criteria:
Additionally, you can click one of the links in the Source column to display the source of inherited rights.
In some cases, you may want to know the objects to which a principal has been granted or denied access.
You can use a security query to do this. Security queries let you determine which objects a principal has certain rights to and manage user rights. For each security query, you provide the following information:
You specify the user or group that you want to run the security query for. You can specify one principal for each security query.
You specify the right or rights you want to run the security query for, the status of these rights, and the object type these rights are set on. For example, you can run a security query for all reports that a principal can refresh, or for all reports that a principal cannot export.
You specify the CMC areas that you want the security query to search for. For each area, you can choose whether to include sub-objects in the security query. A security query can have a maximum of four areas.
Access levels are groups of rights that users frequently need. They allow administrators to set common security levels quickly and uniformly rather than requiring that individual rights be set one by one.
You can do the following with access levels:
Copy an existing access level, make changes to the copy, rename it, and save it as a new access level. Create, rename, and delete access levels.
Modify the rights in an access level.
Trace the relationship between access levels and other objects in the system.
Trace the relationship
Replicate and manage access levels across sites.
Use one of the predefined access levels in SAP BusinessObjects Business Intelligence platform to set rights quickly and uniformly for many principals.
SAP BusinessObjects Business Intelligence platform comes with several predefined access levels. These predefined access levels are based on a model of increasing rights: Beginning with View and ending with Full Control, each access level builds upon the rights granted by the previous level.
The following table summarizes the rights that each predefined access level contains.
HINT: The following rights are required when using these access levels.
In addition to the predefined access levels, you can also create and customize your own, which can greatly reduce administrative and maintenance costs associated with security.
Consider a situation in which an administrator must manage two groups, sales managers and sales employees. Both groups need to access five reports in the SAP Business Objects Business Intelligence platform system, but sales managers require more rights than sales employees. The predefined access levels do not meet the needs of either group. Instead of adding groups to each report as principals and modifying their rights in five different places, the administrator can create two new access levels, Sales Managers and Sales Employees. The administrator then adds both groups as principals to the reports and assigns the groups their respective access levels. When rights need to be modified, the administrator can modify the access levels. Because the access levels apply to both groups across all five reports, the rights those groups have to the reports are quickly updated.
Rights are set on an object for a principal in order to control access to the object however, it is impractical to set the explicit value of every possible right for every principal on every object. Consider a system with 100 rights, 1000 users, and 10,000 objects: to set rights explicitly on each object would require the CMS to store billions of rights in its memory, and, importantly, require that an administrator manually set each one. Inheritance patterns resolve this impracticality. With inheritance, the rights that users have to objects in the system come from a combination of their memberships in different groups and subgroups and from objects which have inherited rights from parent folders and subfolders.
These users can inherit rights as the result of group membership; subgroups can inherit rights from parent groups, and both users and groups can inherit rights from parent folders.
By default, users or groups who have rights to a folder inherit the same rights for any objects that are subsequently published to that folder.
Consequently, the best strategy is to set the appropriate rights for users and groups at the folder level first, then publish objects to that folder.
SAP BusinessObjects Business Intelligence platform recognizes two types of inheritance:
Group inheritance
Folder inheritance
Group inheritance allows principals to inherit rights as a result of a group membership. Group inheritance proves especially useful when you organize all of your users into groups that coincide with your organization's current security conventions.
In Group inheritance example 1, you can see how group inheritance works. Red Group is a subgroup of Blue Group, so it inherits Blue Group's rights. In this case, it inherits right 1 for granted, and the rest of the rights as unspecified.
Every member of the Red Group inherits these rights. In addition, any other rights that are set on the subgroup are inherited by its members. In this example, Green User is a member of Red Group, and thus inherits right 1 as granted, rights 2, 3, 4, and 6 as not specified, and Right 5 as denied.
When group inheritance is enabled for a user who belongs to more than one group, the rights of all parent groups are considered when the system checks credentials.
The user is denied any right that is explicitly denied in any parent group, and the user is denied any right that remains completely not specified thus, the user is granted only those rights that are granted in one or more groups (explicitly or through access levels) and never explicitly denied.
In Group Inheritance example 2, Green User is a member of two unrelated groups. From Blue Group, he inherits rights 1 and 5 as "granted" and the rest as not specified; however, because Green User also belongs to Red Group and Red Group has been explicitly denied right 5, Green User's inheritance to right 5 from Blue Group is overridden.
Folder inheritance allows principals to inherit any rights that they have been granted on an object's parent folder.
Folder inheritance proves especially useful when you organize the SAP BusinessObjects Business Intelligence platform content into a folder hierarchy that reflects your organization's current security conventions. For example, suppose that you create a folder called Sales Reports, and you provide your Sales group with View On-Demand access to this folder.
By default, every user that has rights to the Sales Reports folder will inherit the same rights to the reports that you subsequently publish to this folder. Consequently, the Sales group will have View On Demand access to all of the reports, and you need to set the object rights only once, at the folder level. In the Folder inheritance example, rights have been set for Red Group on a folder. Rights 1 and 5 have been granted, while the rest have been left unspecified. With folder inheritance enabled, members of Red Group have rights on the object level identical to the rights of the group on the folder level. Rights 1 and 5 are inherited as granted, while the rest have been left unspecified.
Rights override is a rights behaviour in which rights that are set on child objects override the rights set on parent objects. Rights override occurs under the following circumstances:
In general, the rights that are set on child objects override the rights that are set on parent objects. In general, the rights that are set on subgroups or members of groups override the rights that are set on groups.
You do not need to disable inheritance to set customized rights on an object. The child object inherits the rights settings of the parent object except for the rights that are explicitly set on the child object. Also, any changes to rights settings on the parent object apply to the child object.
Rights override example 1 illustrates how rights override works on parent and child objects. Blue User is denied the right to edit a folder's contents; the rights setting is inherited by the subfolder. However, an administrator grants Blue User Edit rights to a document in the subfolder.
The Edit right that Blue User receives on the document overrides the inherited rights that come from the folder and subfolder.
Rights override example 2 illustrates how rights override works on members and groups. Blue Group is denied the right to edit a folder; Blue Subgroup inherits this rights setting. However, an administrator grants Blue User, who is a member of Blue Group and Blue Subgroup, Edit rights on the folder. The Edit rights that Blue User receives on the folder override the inherited rights that come from Blue Group and Blue Subgroup. Complex rights override illustrates a situation where the effects of rights override are less obvious. Purple User is a member of subgroups 1A and 2A, which are in Groups 1 and 2, respectively. Groups 1 and 2 both have Edit rights on the folder. 1A inherits the Edit rights that Group 1 has, but an administrator denies Edit rights to 2A. The rights settings on 2A override the rights settings on Group 2 because of rights override. Therefore, Purple User inherits contradictory rights settings from 1A and 2A. 1A and 2A do not have a parent-child relationship,so rights override does not occur; that is, one sub-group's rights settings do not override another's because they have equal status. In the end, Purple User is denied Edit rights because of the “denial-based” rights model in SAP BusinessObjects Business Intelligence platform.
Rights override lets you make minor adjustments to the rights settings on a child object without discarding all inherited rights settings.
Consider a situation in which a sales manager needs to view confidential reports in the Confidential folder.
The sales manager is part of the Sales group, which is denied access to the folder and its contents. The administrator grants the manager View rights on the Confidential folder and continues to deny the Sales group access. In this case, the View rights granted to the sales manager override the denied access that the manager inherits from membership in the Sales group.
The scope of rights refers to the ability to limit the extent of rights inheritance. To define the scope of a right, you decide whether the right applies to the object, its sub-objects, or both. By default, the scope of a right extends to both objects and sub-objects.
The scope of rights can be used to protect personal content in shared locations. Consider a situation in which the finance department has a shared Expense Claims folder that contains Personal Expense Claims subfolders for each employee. The employees want to be able to view the Expense Claims folder and add objects to it, but they also want to protect the contents of their Personal Expense Claims subfolders. The administrator grants all employees View and Add rights on the Expense Claims folder and limits the scope of these rights to the Expense Claims folder only.
This means that the View and Add rights do not apply to sub-objects in the Expense Claims folder. The administrator then grants employees View and Add rights on their own Personal Expense Claims subfolders.
The scope of rights can also limit the effective rights that a delegated administrator has. For example, a delegated administrator may have Securely Modify Rights and Edit rights on a folder, but the scope of these rights is limited to the folder only and does not apply to its sub-objects. The delegated administrator cannot grant these rights to another user on one of the folder's sub-objects.
Guidelines for planning security
Use the following principles as a guide for planning security in the SAP BusinessObjects Business Intelligence platform.
General Rules
Each right is also referred to as an Access Control Entry (ACE) in the SAP BusinessObjects BI platform and can be set to one of three states: Explicit Denial (D), Explicit Grant (G), and Not Specified (NS).
A list of all ACEs is referred to as an Access Control List (ACL).
A combination of ACEs and states (for example Right to Schedule - G, Right to View - G, Right to Modify - D, and so on) makes up an Access Level.
There are predefined Access Levels: No Access (Not Specified state for all rights), Full Control, View, Schedule, View On-Demand, and there are also Custom Access Levels that administrators can create on their own.
Groups and users in the system are also referred to as principals. In the SAP BusinessObjects BI platform, you give rights to principals on objects (folder, document, application) If a user belongs to more than one group, and there is a conflict in rights assignments between the groups to which the user belongs, the Denied (D) right wins over a Granted (G) right, and the Granted (G) right wins over a Not Specified (NS) right (Deny > Grant > Not Specified).
G + NS = G
G + D = D
G + D + NS = D
D + NS = D
A more specific assignment typically wins over a less specific assignment, such as a user over a group, a subgroup over a parent group, and a sub-object over a parent object. Groups may contain subgroups and/or users. Subgroups and users are treated as members of the parent group. In other words, if a parent group is given
an explicit Grant right to view the folder, the user who is a member of a subgroup of the parent group will have the right to view the folder as well. In this case, only the parent group is listed in the User Security dialog box on the folder while the subgroup is not.
The rights given to the group closest to the user take precedence (without breaking inheritance). In other words, if a user is a member of a subgroup and is not added to the parent group, the user's effective rights will come from the subgroup, and not from the parent group. In this case, both the parent group and the subgroup are listed in the access rights dialog box on the folder. The rights between the parent group and the subgroup may be the same or conflicting, but rights assigned to the subgroup will take precedence.
If a user is added to both the subgroup and the parent group, the calculation of effective rights is the same as if a user belonged to two groups on the same level. Refer to the rule G + D + NS = D.
User rights are of explicit type on the object but of inherited type on sub-objects.
Group rights are always of inherited type.
Explicit rights (the user's rights) on an object overwrite inherited rights (the group's
rights) on the same object.
Security rights can be overridden on lower levels in the folder hierarchy without breaking inheritance. The administrator can combine access levels for a principal which can result in a conflict. In these cases, refer again to the rule G + D + NS = D.
Use access levels wherever possible. These predefined sets of rights simplify administration by grouping together rights associated with common user needs. Set rights and access levels on top-level folders. Enabling inheritance will allow these rights to be passed down through the system with minimal administrative intervention. Avoid breaking inheritance whenever possible. By doing so, you can reduce the amount of time it takes to secure the content that you have added to the SAP BusinessObjects Business Intelligence platform. Set appropriate rights for users and groups at the folder level, then publish objects to that folder. By default, users or groups who have rights to a folder will inherit the same rights for any object that you subsequently publish to that folder.
Organize users into user groups, assign access levels and rights to the entire group, and assign access levels and rights to specific members when necessary. Create individual administrator accounts for each administrator in the system and add them to the Administrators group to improve accountability for system changes. By default, the Everyone group is granted limited rights to top-level folders. After installation, it is recommended that you review the rights of Everyone group members and assign security accordingly.
For in-depth understanding click on
You liked the article?
Like: 0
Vote for difficulty
Current difficulty (Avg): Medium
TekSlate is the best online training provider in delivering world-class IT skills to individuals and corporates from all parts of the globe. We are proven experts in accumulating every need of an IT skills upgrade aspirant and have delivered excellent services. We aim to bring you all the essentials to learn and master new technologies in the market with our articles, blogs, and videos. Build your career success with us, enhancing most in-demand skills in the market.
